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SUMMARY 


NASA’s operational use of advanced processor technology in space systems lags behind its 
commercial development by more than eight years. One of the factors contributing to this is the fact 
that mission computing requirements are frequently unknown, unstated, misrepresented, or simply 
not available in a timely manner. NASA must provide clear common requirements to make better 
use of available technology, to cut development lead time on deployable architectures, and to 
increase the utilization of new technology. 

This paper provides NASA, industry and academic communities with a preliminary set of advanced 
mission computational processing requirements of automation and robotics (A&R) systems. The results 
were obtained in an assessment of the computational needs of current projects throughout NASA. The high 
percent of responses indicated a general need and desire for enhanced computational capabilities beyond 
the currently available 80386 and 68020 processor technology. Because of the need for faster processors 
and more memory, 90% of the polled automation projects have reduced or will reduce the scope of their 
implemented capabilities. The requirements are presented with respect to their targeted environment, iden- 
tifying the applications required, system performance levels necessary to support them, and the degree to 
which they are met with typical programmatic constraints. 


INTRODUCTION 


Purpose and Goals 

NASA’s exploration of space began with the early satellites of Pioneer and Magellan in the 
1950s, continued with manned missions in the 1960s, expanded to the Space Shuttle program and a 
grand tour of the planets with deep space probes in the late 1970s and 1980s, and has now pro- 
gressed to the Space Station Freedom (SSF) Program, which began in the 1980s. Future plans 
include transfer vehicles to support colonization of the moon and eventually manned missions to 
Mars and the asteroids. Each program has built upon the knowledge base developed from previous 
experiences with the attendant increase in the requirements for supporting computational systems, 
automation and robotics. To date, NASA has typically used processors specifically designed for each 
project. For the SSF Program the mandate changed to apply “commercial off-the-shelf’ technology 
whenever possible. This moved planning towards the consistent use of more general purpose 
processors. 

Automation and Robotic (A&R) research has typically been based on symbolic and other 
specialized processing systems to match the characteristics of the languages and tools available to 
the researcher. General purpose computers have been used but performance results typically are not 
as good as that achieved with special purpose processors. To understand the long range impact of the 
move toward general purpose processors on A&R systems, a study was conducted to establish a pre- 
liminary set of requirements and project how well they can be met with general purpose processors. 
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This report provides NASA, industry and academic communities with a preliminary set of 
advanced mission computational processing requirements of A&R systems. The information was 
obtained by the Advanced Processing Technology group of the Information Sciences Division at 
NASA Ames Research Center, by canvassing the NASA centers and the aerospace community with 
prepared questionnaires and personal interviews. The process culminated in a workshop at Ames 
with invited presentations, followed by working group critique sessions. 

The goals of this project were to: (1) quantify the requirements of spacebome A&R systems, 

(2) given the requirements, determine whether sufficient capability was provided in the current space 
processing technology, and (3) if deficient, specify additional capabilities required, along with an 
approach to provide for these requirements. Identified within the context of this report are the 
requirements and insufficiencies of available technology. A subsequent report will outline one 
approach for NASA to follow to reconcile the deficiencies. 


Objectives 

NASA’s missions are becoming increasingly complex and success of these missions will 
inevitably become more dependent on the use of A&R technology (ref. 1). This technology is gain- 
ing acceptance and support from a growing number of astronauts and scientists (ref. 2). NASA will 
move to allow A&R to take over historically tedious but necessary jobs, increase reliability and fur- 
ther enable our continued exploration and utilization of space. It is, however, commonly noted that 
NASA’s spaceborne computational processing technology lags market technology by more than 
eight years. One reason is that requirements for spaceborne computation are usually not specified 
early enough to allow development of a long range upgrade plan. It should be noted that there will 
always be a delay of several years to convert commercial technology to the high reliability systems 
demanded by the space environment. The baseline SSF has attempted to explicitly provide hooks 
and scars for future support and implementation of automation and robotic systems (refs. 3-6). The 
Lunar/Mars Rover programs require automation and robotics technology for both a rover vehicle and 
for building a human habitat. Due to the nature of the environments and the functional capabilities, 
the computational requirements for these future systems will be greater than those for a mere collec- 
tion of representative subsystems (i.e., the whole will be greater than the parts). The integration of 
subsystems, typically done by humans, must also be compensated for in computational processing 
(refs. 6, 7, and private communication from Robert W. Mah, NASA Ames Research Center, 

Moffett Field, Calif.). 


Our motivation in this report was not to justify the use of A&R technology but given its use, 
determine the applications required; system performance levels necessary to support them; and the 
degree to which they are met with typical programmatic constraints. 


Scope and Outline 


Table 1 presents a spectrum of environments over which NASA’s A&R applications occur. The 
range includes ground based systems, aeronautics, low earth orbit platforms and manned space 
stations, to Lunar/Mars exploration and deep space operations. For each environment, the 
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computational processing requirements of support subsystems may vary significantly. It is the areas 
of similarity in these systems that are of special interest to the system designers and component 
providers. Some of the differences and similarities are indicated in this report in the Results section, 
following the description of the spectrum categories. 


Table 1. Operational environment and sample applications 


Environment 

Sample application 

Unmanned SEI — deep space 

Voyager, Galileo, CRAF/Cassini 

Manned SEI 

Lunar/Mars Xfr. Vehicle, Rovers 

Low-Earth orbit (Polar) 

EOS, CSTI 

Low-Earth orbit (Equatorial) 

Space Station Freedom 

Aeronautic/low Earth orbit 

Shuttle, NASP, Launch Vehicles 

Aeronautic 

Experimentation/Scientific F-16, X-29 

Ground: scientific 

Scientific return processing 

Ground: mission operations 

Communication, ground control, support 

Ground: development 

Applications development 


The next section describes the method used to perform the assessment in terms of the three basic 
survey techniques (questionnaire, interviews and workshop). The information and conclusions 
derived from this database is presented in a Results section, using tables and graphs. The signifi- 
cance of these data are presented in a general issues section, focusing on the impact for NASA. The 
last section presents the conclusions of the assessment. 


METHOD 


Questionnaire, Interviews, and Workshop 

To assess the capabilities and limitations of NASA’s A&R systems, the assessment was designed 
to be as comprehensive as possible, both in terms of projects polled and information collected. Three 
methods were used to perform the assessment: an in-depth questionnaire distributed widely across 
NASA, personal interviews conducted with selected project engineers at each of the centers, and a 
workshop held at Ames Research Center that specifically focused on computational processing 
requirements. Additional supporting information has been drawn from referenced reports. An in- 
depth description of the method and the questionnaire form are provided in Appendixes A and B, 
respectively. 
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RESULTS 


The results of the assessment were extensive. The information presented in this section is dis- 
tilled from the 35 completed questionnaires, 59 interviews and 21 presentations at the workshop. All 
who contributed to the content of this report, both formally and in “coffee room” discussions are 
listed alphabetically in Appendix C. Requests for anonymity were respected. The results contained in 
this report emphasize four key issues: 

1. intended operational functionality 

2. computational capabilities required to support full functionality in the targeted environment 

3. achievability of functions 

4. tradeoffs 


NASA’s Requirements 

The requirements for NASA are not so simply stated as “NASA needs XXX amount of memory, 
YYY processing performance and ZZZ reliability with XYZ environmental tolerance.” This simpli- 
fication could indicate that all applications in all environments could be satisfied by a global, all 
encompassing capability, which is not the intent of this report. Organization and presentation of the 
data are key to understanding and fulfillment of the requirements. The results are therefore presented 
in the context of the environments (table 1). Within this format, similarities in basic requirements are 
highlighted. An illustrative subset of the results is presented in the following sections. This includes 
descriptions of the projects as well as their current and anticipated computational requirements. 

There were many issues presented in the assessment, both technical and programmatic. This 
paper focuses on physical problems and solutions; discussion of those programmatic issues is 
deferred to a subsequent report. 


The Global Picture 

Although each NASA environment created unique requirements, some responses were over- 
whelmingly common and warranted special note. At least 90% of the respondents expressed concern 
about additional computational processing capability. Particularly requested were increased CPU 
performance, memory size and access time. Most did not quantify the increase desired, but rather 
said “as much as possible” and “whatever is provided, we will use” and “at least double what is cur- 
rently available.” It is important to note that many of the automation systems were (or are) developed 
with an end application in mind, leaving the specific hardware architecture to be determined later. In 
system designs, the hardware is less of a concern because the “fastest available at the time of deploy- 
ment” was most often what will be used. Therefore, it is usually not until a fully functional applica- 
tion is established that hardware limitations can be quantified. By this time, however, automation is 
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well underway and functionality has to be scaled back to fit the available hardware. On the other 
hand, the robotics projects by necessity design their software to the specific hardware. 

Another major concern was fault tolerance, but respondents admitted that it usually is not seri- 
ously considered in the design until after the initial “prototype system” is developed. This is due to 
the desire to establish feasibility of a function first. Project funding was also commonly identified as 
a primary limiting factor to successful system design and deployment. 

Many reported that “success” of a project is not what was the basis of the initial conceptual 
design. Due to design factors such as processor limitations and funding, sacrifices were consistently 
made and the definition of “success” was continually scaled back and redefined. This mission 
“success” was common. Such a process occurred recently, in the current SSF design and the ongoing 
scrub activities. 

NOTE: A majority of those interviewed were from the research side of NASA as opposed to the 
operational side. Therefore, concepts of success tend to have a different meaning. Researchers strive 
for demonstration of proof of concept and tend to continually improve the end product as thoughts 
and requirements change during the development cycle. Program managers, in contrast, must live 
with specific budgets and schedules and are often willing to settle for less than perfection to meet a 
milestone and a delivery date. Neither of these views are wrong, both are reasonable in the evolution 
of space flight. 


Environmental Implications on Computational Systems 

The architectural design of a computational system depends not only on the application but also 
on the environment for which it is targeted. For each environment, issues will receive different levels 
of priority as presented in table 2. Although each area listed places different priority levels on the 
technical issues, all are of importance. It should be noted that the numbers given in each category are 
relative, both to the issues in each column and to the other environments in each row. For all envi- 
ronments other than ground development, fault tolerance and reliability was of utmost importance in 
the deployed system. The following is a description of the relevant issues for systems relative to their 
end environment. 

Technical Issues- The technical issues listed in table 2 are categorized into three areas: 

(1) System Performance, which focuses on the final hardware used; (2) Environment, with consid- 
erations related to end deployment; and those which come from (3) the overall Mission. Although 
more issues were raised than are shown in table 2, those most referenced throughout the assessment 
are presented now with their definitions. 

Performance issues definitions. 

CPU performance : Typically the throughput of a specific set of benchmarks, measured in MIPS. In 
any computational processing system, speed is always a consideration. It is either a primary prefer- 
ence or mandated by application timing constraints. In those categories that speed is secondary, it is 
because compensation for environmental hazards is the primary factor. 
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Table 2. Program and mission priorities 8 


Ground 


Application environment 
Aeronautic Low Earth orbit 


Space 

SEI 


Deep space 


Issue 


Development Operational Science Experiment Launch Equatorial PolarManned Unmanned Platform 

communications 


Performance 
cpu performance 

3 

2 

2 

2 

2 

2 

2 

2 

2 

2 

Memory size 

3 

2 

3 

2 

1 

2 

2 

2 

2 

2 

Communications 

4 

2 

3 

2 

2 

2 

2 

2 

2 

2 

bandwidth 

Environment 

Power (watts) 

4 

3 

4 

3 

3 

1 

I 

1 

2 

1 

Weight 

4 

3 

4 

1/2 

2 

1 

1 

1 

1 

1 

1 

1 

Temperature 

4 

3 

4 

2/3 

2 

1 

1 

i 

4/5 

Vibration 

5 

5 

5 

2/3 

2 

3 

1 

3 

2 

Radiation 

5 

5 

5 

4/5 

2 

2/3 

1 

1 

1 

1 

hardness 

Noise 

5 

5 

5 

2 

1 

4/5 

4 

3/4 

2/3 

4/5 

Mission 

Mission duration 

5 

3 

5 

3 

3 

1 

1 

1 

1 

1 

Real time 

3 

2 

3 

1 

1 

1 

2 

1 

1 

1 

performance 

Fault tolerance 

4 

2 

4 

3 

1 

1 

1 

1 

i 

1 


a top priority = 1, preferential = 3, little/no consideration = 5. 


Data storage : Size of RAM and on-line memory. Data storage affects the application size and the 
amount of data that can be collected and stored. A prime resource in all off-ground applications, it is 
admittedly limited so as to enhance reliability and reduce maintenance costs. 

Network bus bandwidth : The amount of data within the system that can be accessed and the time it 
takes to access it directly affect the end system speed. Necessarily an issue in system design, it is 
often readily accommodated, e.g., by fiber optic cabling. 

Communication bandwidth'. Amount of I/O data. Communication bandwidth is critical in telemetry 
situations and those where real-time applications are dependent upon constantly changing environ- 
mental data. 

Environment issues definitions and comments. 

Power: Required to keep the system running, typically in watts. Power becomes a prime design fac- 
tor for space systems where power is a limited resource. 
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Weight (mass): System physical size is necessarily limited by the resources in the environment. 
Physical area is a resource for experimental aeronautic systems and for those in space. The smaller a 
system is, the less power it should consume, not only in the act of deploying but also in its continued 

use. 

Temperature: Heat dissipation is a concern relative to the speed of the system (performance) and the 
deployed environment. This issue is typically satisfied by packaging techniques. 

Vibration: Deploying a system to its end environment involves physical movement of the system. 
This includes inertial vibration, stability ranges, shock and spin. Vibration tolerance is also handled 
in the packaging. 

Radiation hardness: Shielding of systems in hostile environments which may consider internal 
radiation (neutrons), rad-hard single dose and total dose, latchup-proof, cosmic rays and single event 
upsets. The levels for which designs are needed depend on the orientation in space. For example, 
radiation was a factor in placement of Space Station Freedom below 290 nautical miles. Beyond this 
altitude energy impacts increase significantly, which increases the probability of electronic data and 
command path disruptions. 

Noise: Electrical noise both internal and external to the system affect the performance and reliability 
of the information input to and supplied by the system. Due to advancements in technology, this is 
not a restricting factor on system designs. 


Mission specific issues. 

Mission duration: the longer a mission, the more critical component reliability and system fault tol- 
erance become to the system design process. Ground systems can be readily maintained by field 
support service personnel. Aeronautic systems, with missions varying from within one hour for air- 
craft to weeks for the shuttle receive regular ground maintenance. Deployed space systems have 
some capability for telemetered command reconfiguration but onboard hardware is a limited 
resource and is generally not maintainable. 

Real time: the smallest unit of time allocated and its associated criticality for the task at hand. This is 
a critical issue for the operations support in life and mission-critical systems in aircraft and shuttle, 
as well as life support systems in SEI. 

Fault tolerance: refers to the system ability to detect and tolerate both hardware and software system 
faults. System granularity and ranges of tolerance are based on mission, function, duration, and criti- 
cality to life. 

Reliability: Typically cited with fault tolerance, the statistic often provided in MTBF and MTTR, 
indicating the ability of the system to perform designated functions in whole and reconfigured states. 


As stated, the entries in table 2 are relative, not only among separate issues, but also between the 
different application environments. For example, environmental radiation has no impact on design of 
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ground systems and limited influence on aircraft systems. However it becomes a much higher prior- 
ity issue in designs for those systems that are deployed in space. Deep space systems are necessarily 
designed primarily to tolerate this processing hazard. Likewise, in striving to accomplish a mission, 
cpu performance, memory size and communications bandwidth are of concern to system designers 
for deep space missions, but these must be secondary to the environmental factors. 

The questionnaire results are presented in tables 3-8 with their associated project descriptions 
found in Appendix D. The following sections summarize the general issues and concerns relative to 
the environments and the goals they sought. Although a limited set of projects are presented, they are 
representative of the most referenced issues identified. 

The full set of results obtained in the assessment have been deferred to Appendixes D and E. The 
reader is encouraged to refer to these appendixes for supporting information. Programmatic and 
philosophical orientations and the impact these had on designs will also be found. 


Ground Systems 

Computational processing systems for ground use are not unique, relative to other environments. 
Any system designed for flight or space has a corresponding counterpart for ground, but not vice 
versa. 

The top priority for selection of the ground-based systems was typically CPU performance. If 
unlimited resources were available, the fastest processors with the greatest available support would 
be used for development, mission operations and analytical applications. When necessary, reliability 
can be designed without regard to power and mass considerations. The software design is easily 
focused without much limitation in memory size. Maintenance tasks are readily accomplished when 
failures occur, allowing fault tolerance concerns to be less important than other issues. Within the 
scope of the assessment, the ground systems presented a relative lack of “issue concerns.” 


Aeronautic Systems 

It can be argued that aeronautical systems are the most demanding on computational processing, 
primarily due to real-time interrupt and task-switching performance constraints. Reliability is of 
utmost importance to the mission and human life support, and must also be designed in from the 
outset. These systems must maintain ultrahigh reliability, facilitated by the extensive use of fault 
tolerance. 

As seen in table 9, CPU power and memory size are primary limitations to deploying advanced 
automation capabilities. Enabled, these would enhance fault tolerance testing, increase system avail- 
ability, and offset some of the pilot workload. Rather, with the exclusion of these capabilities, the 
pilot workload is increased as he or she must integrate increasing amounts of data, and from there the 
mission reliability is decreased. 
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Table 5. Survey responses 
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Table 7. Survey responses 
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Table 8. Survey responses 
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Table 9. Aeronautic requirements 


Vehicle 

Function 

Key requirement 
(current -> need) 

Limitation 

Sacrifice 

Compensation 

X-29 

System information 
management 

<0.5 -> 10 MIPS 

CPU 

Reduced 

control 

mode 

Pilot load 

F-18 

Sys. model F.T. 

Real-time, qualified 

CPU, memory 

Reliability 

Defer to 
ground 

CV-990 

Optimum fuel use 

Existing hardware 

Memory 

Model com- 
plexity 

None 


When more computing power becomes available, specified as a lOx increase over the current 
0.5 MIPS, and more memory than the range of 128KB to 512KB, the following would be added: 

• increased onboard testing, 

• incorporation of vehicle system health monitoring, 

• enhanced software programs which can adapt to and compensate for a range of hardware 
failures, and 

• implementation of all of the above in a higher order language. 


Low-Earth Orbit Systems 

Launch vehicles present a new mix of processing requirements, involving the real-time perfor- 
mance of aeronautic systems and the environmental and extended mission considerations of space. 
System reliability is of primary importance and changes in software are not realized as quickly as for 
research aircraft. However, because aeronautic and launch systems are maintained regularly on 
ground, the upgrades are more readily achieved than for deployed space systems. 

Technology programs necessary to demonstrate flight critical avionics architecture for next gen- 
eration space launch vehicles have been identified (ref. 8). The Multi-path Redundant Avionics Suite 
(MPRAS) System/Subsystem presents requirements for advanced space launch vehicles, stressing 
that “autonomous flight and ground operations are key features” to the successful system. An 
analysis of the three candidate configurations defined and presented is summarized in table 10. Each 
configuration presents increasing degrees of autonomy, operating in the same mission scenario. Con- 
figuration 1 represents a partially reusable ascent stage with fully reusable flyback boost stage; con- 
figuration 2 is a partially reusable ascent stage with partially reusable boost stage; and configuration 
3 represents a totally expendable ascent stage and boost stage. As stated in the report (ref. 8), “these 
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Table 10. MPRAS requirements 
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requirements are intended to represent mid-term launch vehicles such as for the Advanced Launch 
System (ALS) and to provide the requirements from which a range of conceptual avionics architec- 
tures can be generated for each of the configurations.” As can be seen, the performance requirements 
of the total system vary from 17 to 20 MIPS. The radiation dosage is relatively small, with a maxi- 
mum reported at 4 rads Si for total dose to the vehicle. The full details of these requirements are 
found in the referenced report. 

The upgrade to the new general purpose computer (GPC) of the space shuttle program, with a 
threefold increase in processor speed over the previous GPC, yields a potential for a 40% increase in 
system performance. It is unclear whether this capability will be sufficient for the studied 
configurations. 

Three other projects assessed are outlined in table 11. Each of these is developed to be 
compatible with the Space Shuttle. The Knowledge-based Autonomous Test Engineer (KATE) is a 
large production system designed to support real-time diagnosis and control of systems. It can be 
applied to ground, flight or space systems. The primary focus of this system is analysis and 
intelligent control through software. Due to the type of application, this is a large system that could 
benefit from as much speed up as possible in system performance. Because KATE was designed to 
be general purpose, the computational processing requirements are necessarily dependent on the 
system to which it is applied. In the various current applications, 5 to 100 MIPS system throughput is 
required. However, unspecified increases in system performance are required for some applications, 
particularly off-ground, and desired for all others. For this system, the Lisp language, the dynamic 
memory allocation scheme associated with it, and the technology’s inherent verification and 
validation issues were all cited as the limitations realized in achieving success in off-ground 
deployment. Investigations are currently underway in translating the system from Lisp into a 
conventional language, such as C or Ada. This example is typical of most automation programs 
currently in development. 

To incorporate system health monitoring into the second generation main engine controller of the 
Space Shuttle requires a speedup of 20 times that available with the current system. The sacrifice is, 
as in most deployed systems, system testing. 

The Super-fluid Helium On Orbit Transfer (SHOOT) project has been designed from the begin- 
ning as a single-time payload experiment, primarily as a demonstration of automation technology. 
The platform and interface were specified by the shuttle office. Successful automation will be 
demonstrated, however a more capable hardware system, with faster processor speed and larger 
memory, would enable deployment of a more sophisticated system with increased error detection 
and diagnosis. 
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Table 11. LEO launch requirements 



Functionality 

Key requirement 
current (need) 

Limitation 

Sacrifice 

Compensation 

KATE 

r.t. diagnosis and 
control 

5-100 MIPS 
(as much as 
possible) 

Language, 
v&v, 8MB 

Usage in space 

Translation? 

SSMEC 

Engine control 
health monitor 

0.5 MIPS 
(10 MIPS) 

Speed, parts 
reliability 

Onboard testing 

Assembly language 

SHOOT 

Fault diagnosis 

4 MIPS (TBD) 

Memory size, 
speed 

Fault handling 

None 


Space Station Freedom Systems 

The SSF is designed to sustain a 30 year mission with first element launch scheduled for 1995. 

Its mission is to support international scientific research labs investigating physics, material and life 
sciences and performing astronomical and earth observation. The SSF is also intended to support the 
Lunar/Mars missions. 

In addition to those given in tables 3-8, specific requirements regarding advanced automation 
capabilities targeted to support the SSF are presented in table 12. The typical limitation identified for 
these functions is the projected real processing speed of the i80386 processor. Although the exact 
requirements necessary for fulfillment of the functions were not identified, it was clearly stated that 
the technology described in this paper is insufficient to perform the tasks as defined. The sacrifice 
realized because of the limitations is typically in system reliability, either by a reduced model of the 
system used in fault tolerance or as a loss of basic data. It was indicated that the functional capability 
of some payload operations would not be achieved at all, without the capability of a space qualified 
symbolic processor. This was indicated by two different advanced automation programs, currently 
developed in Lisp, using symbolic-processing machines. 

Detailed in a recent report by Dr. Michael Ring of Advanced Technology and Research Corpo- 
ration (ref. 10), the basic functions for the Flight Telerobotic Servicer (FTS) are achievable with 
currently available technology. Some of the requirements identified by the general software organi- 
zation for the FTS are presented in table 13. Designed specifically for tele-operation, the hooks and 
scars are to be in place for upgrading to autonomous operation. 

Optimally, the upgrades would include vision processing. Although detailed requirements were 
not indicated to support vision processing, table 14 presents a preliminary outline. The basic opera- 
tional capabilities of the tele-operated robot would likely preclude this upgrade from being achieved. 
Indications are that support of the growth capabilities of the flight telerobotic servicer requires much 
more processor capability than is currently available. 
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Table 12. Space Station Freedom requirements 



Function 

Key requirement 
now (need) 

Limitation 

Sacrifice 

Compensation 

SSF 

House-cleaning robot 

4 MIPS (TBD) 

cpu speed 

TBD 

Crew 

SSF 

Mission planning 
payload operations 

4 MIPS (TBD) 

Symbolic 

process 

Capability 

Crew, elec- 
tronic mail 

PMAD 

(MSFC) 

Management, diag- 
nosis recovery 

27 MIPS 
(significant 
increase) 

cpu, memory 

Model com- 
plexity 

None 

FTS 

Telerobot 

40 MIPS (TBD) 

Algorithm 

(cpu) 

None 

N/A 

ECLSS 

Intelligent control 

Compatibility 

cpu speed. 

Fault detec- 

Defer to 


life support system 

with SSF 
(symbolic) 

memory, 

language 

tion han- 
dling 

ground 

TCS 

Real time tempera- 

10 MIPS 

cpu speed. 

Hypothetical 

Ground 


ture control 

(40 + MIPS) 

language 

reasoning 


AANMS 

Network monitor 
fault management 

10 MIPS 
(400 MIPS) 

cpu speed 

Loss of data 

Intermittent 

sampling 


Table 13. General software organization of FTS 

Level 

Function 

Clock rate 

Proc. power 

w/Data transfer 

Manipulation primary level 
Manipulation servo level 


20 Hz 

17 kflops 

26 kflops 

(7 DOF w/FTT) 

Sensor mod pro- 


0.4 kflops 



cessing, rt con- 

200 Hz 

90 kflops 



trol inertia, etc. 

20 Hz 

45 kflops 
135 kflops 

202 kflops 

(6 DOF w/FTT) 

Real-time inertia. 

200 Hz 

60 kflops 



etc. 

20 Hz 

30 kflops 
90 kflops 

135 kflops 

Hand controllers 



33.8 kflops 

51 kflops 

Total 




212- 279 kflops 
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Table 14. Processing requirements for vision incorporation to FTS (in Kfiops) 


Level 

Vision 

Safety 

Manipulator 

Total Kfiops 

Elementary 

2000 

2500 

3300 

7800 

Primary 

— 

39 

78 

117 

Servo 

— 

270 

641 

911 

Total 

2000 

2809 

4019 

8828 


Low Earth Orbit Polar Systems 

The difference between this section and the previous is the mission type. Whereas the SSF is 
designed to support human life, low earth orbiting polar systems emphasize science experiments and 
have no crew. They tend to be the most benign of the off-ground systems to design because the envi- 
ronmental factors are comparable to those of the SSF and their mission functions are for communi- 
cations and scientific return. 

Responses in the assessment by the EOS management indicated that the use of the 1750A pro- 
cessor was more than adequate for their onboard processing requirements, which were admittedly 
minimal. There are no plans for upgrades to this system. Full details on this project are available in 
the appendices. 


Unmanned Space Exploration Initiative Systems Mars Rover Telerobotics 

The projects entailed within the SEI program are the most complex in terms of functional capa- 
bility. This is due primarily to the integration of each of the resident subsystems of the robots and 
rovers. 

Development of rover technology for Lunar and Mars exploration is a difficult task because 
requirements for this unique scenario do not exist. The overriding functionality is that the rover is to 
perceive its environment and plan its path. Every meter travelled requires X amount of processing. 
100 Gflops capability for 60 meters/day should be sufficient. 

The computational and data storage requirements for the planetary rover are presented in 
tables 15 and 16 (ref. 10). The planetary rover must sufficiently support computational requirements 
of onboard navigation activities, which involves manipulation and storage of large databases, stereo 
correlation, terrain matching and path planning. Robotic processing includes the real-time command, 
control and data management of science and engineering subsystems. The summarized requirements 
presented may vary by an order of magnitude, depending on the mission scenario used. These 
requirements are represented in table 15 in system form. This indicates a range of computational 
requirements for planetary rover navigation, based on specified mission scenario with rover velocity 
and roundtrip light time delays. 
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Table 15. Rover processing requirements 


Function 

Storage, 

Mbits 

MOPS/ 

Cycle 


MOPS/ 
10 Meters 

MIPS 

Structured light vision 

109 

6.5 

5 

325 

VAR 

Full stereo imaging 

337 

1000 

0.5 

5000 

VAR 

Modified stereo imaging 

TBD 

76 

0.5 

380 

VAR 

Laser scanner 

8.2 

118 

5 

5900 

VAR 

Radar sensor 

1.95 

10 

0.2 

20 

VAR 

Path planner 

80 

250 

0.1 

250 

VAR 

Terrain matching 

121 

500 

0.1 

500 

VAR 

Traverse simulation 

TBD 

200 

0.1 

200 

VAR 

Execution monitoring 

TBD 

250 

0.1 

250 

VAR 

Sequence planning and 

TBD 

250 

0.1 

250 

VAR 

generation 

System monitoring and 

TBD 

N/A 

N/A 

N/A 

0.5 

replanning 

Vehicle control 

TBD 

N/A 

N/A 

N/A 

0.3 

Manipulator control and 

421 

2.25 

N/A 

N/A 

? 

sampling 

Telemetry handling 

634 

0.75 

N/A 

N/A 

0.075 

System fault protection 

>1000 

34 

5 

170 

20% (total) 

Command and data 

8 

1.0 

N/A 

N/A 

0.3 

handling 

Power and thermal man- 

0.004 

0.001 

N/A 

N/A 

0.05 

agement 

Science 

54000 

? 

N/A 

N/A 

? 


Figure 1 shows the identified trends in computational requirements for navigation of planetary 
rovers (ref. 10). The simplest of scenarios indicates that requiring 0.5 to 2 MIPS capability are push- 
ing current performance limits of available processors. The construction vehicles’ requirements of 
5000 to 50,000 MIPS are well beyond most processing capabilities of even advanced ground tech- 
nology. The goal of relating this information to the available space-qualified processors, will proba- 
bly never be met expeditiously without an active leadership role by those who need the extensive 
capabilities. 
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Table 16. Rover computational processing requirements by scenario 


Vehicle 

Lunar survey rover 
8.3 cm/sec (5 m/cycle) 

Mars exploration 
rover 
1.2 cm/sec 
(10 m/cycle) 

Mars 

construction 
rover 
1 .0 m/sec 

Lunar 

construction 
rover 
10 m/sec 

Capability/function 

CARD 3 , human opera- 
tor plans, telemeters 
commands 

Semi-autonomous 

navigation 

Continual movement, 
onboard sensing, 
perception and planning 

Onboard navigation 
requirement 

0.5 to 2.0 MIPS 

1 to 10 MIPS 

500 to 
5000 MIPS 

50.000 to 

500.000 MIPS 

Average travel time 

50 sec 

1.66 min 

Continual 

Continual 

per cycle 

Average planning time 

10 sec 

12.7 min. 

Continual 

Continual 

per cycle 

Other 

15 Krads total dose, SEU is TBD, temperature range -20 to 

i +40 C 


a CARD = Computer Aided Remote Driving 


Id 10 Inst/meter 



Figure 1. Estimated computation for navigation of planetary rovers. 
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Manned SEI 


Planet surface systems- One presentation at the workshop was Space Exploration Initiative 
Planet Surface Systems Computation Needs. This talk identified case studies which were performed 
for the Office of Exploration (code Z) to point designs for potential Lunar and Mars exploration pro- 
grams, including expeditions, observatories and outposts. The study resulted in the recommendation 
to establish a lunar outpost, followed by a Mars expedition, and then settling a Mars outpost. 

The timeframe for establishing the outposts indicates a first piloted flight to the Lunar emplace- 
ment (enabling key capabilities and establishing of initial facilities) to be in the year 2000 and the 
first piloted expedition to Mars in 2014 and first piloted evolution to Mars in 2023. While it is still 
too early to select a processor or estimate the size of software required, definition of the top level 
requirements makes the architectural implications undeniable. The primary factor is providing a safe 
haven for crews of 4 to 8 people deployed on 6 to 12 month tours. The requirements for the con- 
struction vehicles given in the previous section are only the starting point. These can readily be 
extrapolated from the requirements presented in the Rover Technologies section. 


Deep Space 


For deep space systems, the influencing design factors are undeniable. Once deployed, the 
systems are unserviceable and therefore reliability must be built in. Also, autonomy in this arena 
carries its own definition. A requirement is to survive 24 hours with no commands, therefore being 
in “safe mode” of self-preservation. This is the “autonomy.” The radiation levels and the temperature 
range to which systems are subjected continue to keep components available for these systems at a 
minimum. Finally, scientists set the requirements for the onboard computational processing capabil- 
ity. Typically, no matter what capability is offered, they want more, faster, capabilities. Scientific 
requirements are endless. Some of the basic requirements presented for deep space computers are: 

1. Radiation: 100K to 200K RADS (Si) 

2. Latchup proof 

3. SEU resistant = <10E-10 Bit Flips/Bit-Day or »37 Mev/mg/cm2 

4. No dose rate or neutron requirements 

5. Temperature = (-30 C to +85 C) 

6. Voltage ±10% 

7. >10 year mission life: high quality components (MIL-M-38510: Class S) 
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The platforms surveyed were Voyager, Galileo and CRAF/Cassini. The computational require- 
ments necessarily increased as the capabilities of the systems grew. Table 17 provides the range of 
system requirements for three systems which ’’evolved”. 

Table 17. Space computational requirements 


Mission 

Year deployed, 
length 

Processor 

performance 

Other requirements 

Problems 

Voyager 

1972(12+) 

150 KIPS 

Dual redundant; 

Time and memory 


(extended past 3) 


538 Mbits Storage 

margins = 0 

Galileo 

1978 (10) 

250 KIPS 

Same as above + extra; 

Time and memory 




finer granularity F.T. 

negative since 1983 

CRAF/Casini 

1995(12) 

400 KIPS 

Automated FDIR 

N/A 


Providing a true evolutionary perspective, the most notable of these lessons learned are: 

1. Control requirements, not data requirements, drive the computer needs 

2. Speed margins are at least as important as memory margins 

3. Beware new microcode: subtle bugs are detected through years and thousands of hours of 
operation. 

CONCLUSIONS 


Many issues have been raised throughout the assessment, some application-specific, but even 
more that are common to most NASA programs. Of the survey, workshop and interview data 
collected, 90% of those responding expressed concern that NASA’s deployed systems are not as 
capable as they should be (indicating various reasons) and that available processing technology is 
one of the major problems. Although NASA has been forced to use what was available, this is not 
without mission sacrifice. This sacrifice is defined as either: 1 ) the initial functional design of a 
system could not be deployed with existing technology and thus had to be reduced in scope; or 
2) that the end system functionality was intentionally defined to the existing hardware capabilities, 
fully recognizing that this system would not be as capable due to the end hardware being space 
qualified, rather than ground operational. The identified problems can all be categorized in two 
related areas: limited selection of qualified processors, and the fault tolerance of system designs. 
More explicitly, the following can be concluded: 

1. “Qualifiable” Technology is sufficient for most kinds of applications. 
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2. A perception among the researchers is that AI and expert systems are limited by techniques 
(verification and validation) and hardware (support of programming language). 

3. Image Processing with real-time control is the most demanding on computational processing 
and connectivity resources. These capabilities are not adequately met with existing 
technology. 

4. Fault Tolerance was found to be the most neglected in system design, nominally taxing sys- 
tem throughput by 20 to 40%. 

5. Benchmarks for evaluation of system performance are inadequate. 

6. Technology standards is key to re-use, maintenance, and efficient, optimal system designs 
across missions of current and future time. 

Most of the requirements cited can be satisfied by currently qualifiable technology. Many of the 
ground workstations are based on processors and designs that have no inherent limitations on being 
generated in a space qualified form. The problem is not in what could be qualified, rather what is 
qualified. 

Factors used as tradeoffs in system design lend themselves to either restricting or enabling the 
end system functionality. The CPU performance, power allocation, memory size allocation, language 
used and funding are adjusted interdependently. 

Everything depends on funding. Although the level of funding is necessarily a restriction, it is the 
fluctuation in funding once a design is set that results in reduction of capabilities and often reduced 
reliability. With this, system fault tolerance is typically the compromising catch all in system 
tradeoffs. 

Finally, typically resolvable programmatic issues are often limiting factors of mission success. 
There are differences between operations-and-project and research-and-development perspectives. If 
identified and recognized early in system design, any ill effects could be minimized. These will be 
presented in a subsequent internal report. 

To enable automation in space, AI and expert systems technology must be supported in the 
deployed system. This can be accomplished in various levels of the design, whether it be at the 
hardware architecture level of providing special purpose processors specifically supporting symbolic 
processing, or general purpose systems that make up for list processing in the raw speed. It is not so 
simple to indicate that special architectures should or should not be qualified. Automation must be 
supported. To enable its successful deployment in space, further accomplishments must be made, 
specifically in 1) v&v of the systems, and 2) support of the process execution efficiency, either in the 
hardware or the software, or both. 

NASA cannot afford to continue operating in the status quo of focusing on isolated projects and 
their specific problems, finding quick solutions for the current problems. A plan must be adopted 
that will allow evolution of architectures based on projected mission requirements. Even though 
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many requirements are not stated and researchers provide only guesses, they do represent prelimi- 
nary requirements to be used as technology goals. In the end, it will be necessary to enable advanced 
automation technology, not limit it by default. 
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